1. Technical Field of the Invention
The present invention generally relates to optical burst switching (“OBS”) networks. More particularly, and not by way of any limitation, the present invention is directed to a method and apparatus for supporting operations and maintenance (“OAM”) functionality in such networks.
2. Description of Related Art
In burst switching technology, such as, in particular, optical burst switching (“OBS”) technology, data bursts (“DBs”), each of which is made up of multiple packets, are switched optically at core nodes, or routers, in the OBS network. A small control packet, called the Burst Header Packet (“BHP”) travels an offset time ahead of each DB along the same DB route and configures the optical switch for the duration of the DBs at the core node. In short, each BHP travels an offset time ahead of its associated DB and establishes a path for the DB.
Two primary features distinguish OBS networks from other types of optical networks that one must bear in mind with regard to Operations and Maintenance (“OAM”) issues in OBS networks. The first is that spectral (i.e., spatial) decoupling is used in transmitting a BHP and the DB associated therewith transparently from ingress to egress edge nodes with possible wavelength conversion for contention resolution at intermediate optical core nodes. As a result, both a proper mechanism to check on correlation between a DB and its associated BHP in the passage from ingress to egress edge nodes and a network-wide wavelength reference to offer wavelength standard to each node are required. Second, temporal decoupling between a BHP and its associated DB, which are modified/updated at each intermediate node, exists. This requires that timing information for each DB and BHP pair must be maintained until they reach the egress OBS edge node.
It is these two distinctive characteristics of OBS networks that may generate another set of OAM requirements and warrant a fresh look into OAM issues in connection with OBS networks. There are several potential OAM implementation problems in OBS networks caused by these features. Such potential problems include out-of-synchronization receipt of BHP and DB, orphan BHPs and DBs, optical switch fabric misconfiguration, burst misrouting, burstification process malfunction, and out of sequence arrival of bursts at the destination edge nodes, to name a few.
Operations and Maintenance (“OAM”) architecture can be broken down into four main levels. The first such level is a functional architectural level, in which OAM architecture is considered in relation to OBS functionality. The second such level is a network architectural level, in which all necessary building blocks to provide OAM functionality on a network-wide level are identified along with their defined inter-relationships. The third such level is an informational and communication architectural level. This level addresses a model of communication, as well as an exchanged informational model among entities in the OAM architecture. The last such level is a node architectural level. This level describes how the previous three levels can be realized and integrated into an OBS node so as to achieve OAM objectives. At the node architectural level, the fundamental OAM building blocks needed to carry out OAM functions are provided and their interactions with other parts of the OBS node infrastructure are defined. In contrast to the network architectural level, focus at the node architectural level is on local OAM activities.
Currently in OBS networks, there is a lack of OAM functionality in the edge and core nodes to support performance monitoring, fault management defect and failure detection, and related information dissemination.